Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Rubocop to v0.52.1 for Zendesk plugin #2

Closed
wants to merge 5 commits into from

Conversation

nicoleheejin
Copy link

@nicoleheejin nicoleheejin commented Jan 22, 2018

Pull Request Checklist

Is this in reference to an existing issue?
Yeah! sensu-plugins/community#77

General

  • Update Changelog following the conventions laid out on Keep A Changelog

  • Update README with any necessary configuration snippets

  • Binstubs are created if needed
    Fails for me due to unrelated code, will take a look afterward

  • RuboCop passes

  • Existing tests pass

Purpose

There's a CVE out for Rubocop, and this fixes it. sensu-plugins/community#77

Known Compatability Issues

None to my knowledge.

@majormoses
Copy link
Member

Thank you for submitting this, I will review shortly.

Copy link
Member

@majormoses majormoses left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks great! some minor things regarding our community contribution practices, once they are addressed I am 👍 Thank you very much for taking the time to do this.

@@ -4,6 +4,11 @@ This project adheres to [Semantic Versioning](http://semver.org/).
This CHANGELOG follows the format listed at [Keep A Changelog](http://keepachangelog.com/)

## [Unreleased]

## [1.1.0] - 2018-01-21
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the other PR, our changelog conventions all submitted changes go under ### [Unreleased] there are a couple of reasons for this:

  • There is no guarantee when a maintainer will review so the release date will likely be wrong unless we get to it in the same day
  • There is no guarantee on the review/merge order, bumping the version prior to acceptance is pretty much guaranteed to need to have the submitter rebase
  • Maintainer may disagree on how you interpret the change, for example in this case you versioned a as a patch when in fact it is a breaking change as you drop a version of ruby being supported. Even when an update is in the name of security we generally follow semver unless there is a very good reason not to such as putting the consumer at extreme risk. This is outlined as it relates to security here if you are interested in understanding how we handle these edgecases.

@@ -4,6 +4,11 @@ This project adheres to [Semantic Versioning](http://semver.org/).
This CHANGELOG follows the format listed at [Keep A Changelog](http://keepachangelog.com/)

## [Unreleased]

## [1.1.0] - 2018-01-21
### Changed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the other PR, this should actually go under a ### Security header rather than changed as it makes it clear to consumers that this update is important and should be prioritized over pulling in other types of changes.


## [1.1.0] - 2018-01-21
### Changed
Bumped Rubocop to v0.52.1 for CVE 2017-8418 (@nicoleheejin)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To keep things consistent with the other PR's we should bump it to ~> 0.51.0 which satisfies the requirement to patch the vulnerability and reduces the number of new cops to satisfy.

@@ -21,23 +21,23 @@ Gem::Specification.new do |s|
s.platform = Gem::Platform::RUBY
s.post_install_message = 'You can use the embedded Ruby by setting EMBEDDED_RUBY=true in /etc/default/sensu'
s.require_paths = ['lib']
s.required_ruby_version = '>= 2.0.0'
s.required_ruby_version = '>= 2.1.0'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the other PR, this needs to be called out in the changelog under ### Breaking Changes so that we inform users on the impact and make it more obvious to reviewers and maintainers so it can be evaluated and versioned appropriately.

s.add_development_dependency 'rspec', '~> 3.4'
s.add_development_dependency 'rubocop', '~> 0.52.1'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To keep things consistent with the other PR's we should bump it to ~> 0.51.0 which satisfies the requirement to patch the vulnerability and reduces the number of new cops to satisfy.

@majormoses
Copy link
Member

@nicoleheejin checking back to see if you can make those changes so we can get this merged and released.

@mbbroberg
Copy link

Hey @nicoleheejin! We're going to move forward with #3 as a fix over this PR. It's our bad that it wasn't clear which version of rubocop to address - hopefully that's clearer now with updates to sensu-plugins/community#77. And we totally understand people get busy, so I hope you'll keep contributing when you have the time again. Thank you so much and tons of #monitoringlove.

Closing in favor of #3.

@mbbroberg mbbroberg closed this Mar 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants